Murphy's Law and Computer Security

This paper discusses lessons learned from a selection of computer security problems that have surfaced in the recent past, and that are likely to show up again in the future. Examples are taken from security advisories and from unpublished loopholes in the author’s own work. 1. Widely-known passwords Imagine that you choose a password to protect your systems and then advertise that password in big neon signs for all to see. That would not be a very responsible thing to do. Surprisingly, this is almost exactly what some programs have been doing for a long time. Passwords are the traditional method to authenticate users to computer systems. With todays computer networks, large pseudo-random numbers are being used as password tokens or as cryptographic keys for communication between computer programs. Examples that will be discussed in this paper are Kerberos tickets, X11 magic cookies, and NFS file handles. These password tokens or cryptographic keys are not chosen by people. Instead, a pseudo-random value is generated programmatically whenever one is needed. Unfortunately it is easy to end up with a predictable result. 1.1. Predictable Kerberos keys Recent advisories allude to a problem that allows an attacker to impersonate users of the Kerberos version 4 [Stei88, Kohl93] authentication system. In order to understand the problem it is not necessary to go into the details of how Kerberos works. The problem is with the generation of encryption keys. In the Kerberos system, temporary encryption keys are used to protect authentication information. One of these encryption keys is generated by the authentication server at the very beginning of a login session: it is part of the ticket-granting ticket that allows an authenticated user to obtain service through the network without having to provide a password each time. Unfortunately, the key generation algorithm used by the version 4 authentication server was predictable. Ultimately, all encryption keys were derived from known information (the time of day), from constant information (a process ID and a machine identity), and from predictable information: a counter that was incremented with each call. The result: a cryptographer’s nightmare. Armed with this knowledge, an intruder could impersonate other users without even having to know their password. The code fragment below illustrates the problem: p = getpid() ˆ gethostid(); gettimeofday(&time, (struct timezone *) 0); /* randomize start */ srandom(time.tv_usec ˆ time.tv_sec ˆ p ˆ n++); The fragment shows a fine example of a comment that lies: feeding predictable input into a deterministic routine produces a predictable result. Curiously, the Kerberos version 4 source code already contains an improved key-generation algorithm that does use secret data as input, but the improved algorithm was not put into actual use until the release of Kerberos version 5. hhhhhhhhhhhhhhh 1. Several vendors were already aware of the problem and had taken measures in their own version of the software. 1.2. Only 256 different magic cookies The X Window system [Schei86, Schei92], comes with the XDM graphical login tool. Some vendors provide their own alternative, but the programs all perform the same basic task: display a logo on the screen and prompt for a login name and a password. When a correct name and password are given, an X session is started. This can be a default desktop that is provided by the system, or it can be a desktop as specified by the commands in a .xsession file in the user’s home directory. When an X application program connects to the X server program (i.e., to the user’s keyboard, screen and mouse), it typically authenticates according to one of three methods: g No authentication: every user on the network has access to the user’s keyboard, screen and mouse. This is the default on too many systems. g Client network address: all users on specific hosts have access to the user’s keyboard, screen and mouse. The client network address is provided by the client host. g Magic cookie: all users that know a 128-bit secret value have access to the user’s keyboard, screen and mouse. The secret is typically kept in a file .Xauthority in the user’s home directory. The secret is sent in the clear over the network. Other authentication methods exist, based on data encryption techniques, but their use is less common. Authentication methods differ in strength. Authentication with magic cookies is more secure than authentication by client network address. Authentication by network address, in turn, is a lot more secure than no authentication at all. The XDM program suffers from a problem much like the one described earlier for Kerberos version 4: magic cookies are generated from non-secret data (time of day and process ID). Such cookies can be guessed in a small amount of time if one has access to the victim’s machine. Cookie guessing becomes harder, but not impossible, without access to the victim’s machine: it is still possible to find out the approximate time of login by fingering the host. However, until recently, some XDM implementations suffered from an even worse flaw that made them vulnerable to arbitrary users on the network. A fix was announced in November 1995. The problem was than many implementations of the UNIX random number generator are truly horrible: the low 8 bits of its result repeat with a cycle of length 256. These low 8 bits are exactly what some XDM implementations use when they generate a magic cookie: for (i = 0; i < len; i++) { value = rand(); auth[i] = value & 0xff; } With a cycle of length 256, there can be only 256 different magic cookies! It takes only a fraction of a second to try them all and to find out which of the 256 magic cookies an X server is using. It is as if every other house has the same key to the front door. Fortunately, many XDM implementations are not vulnerable to this particular problem: they either use a better random number generator or they use an algorithm that involves cryptography. 1.3. Identical NFS file handles In a discussion of security loopholes, the Network File system [Call95] cannot remain unmentioned. The fsirand flaw that I describe here was found and fixed in SunOS 4 years ago. In order to explain the problem I will describe the NFS protocols in a nutshell. When an NFS client host wants to access a remote file or directory, it sends a request to the file server’s NFS daemon. The request includes an NFS file handle that identifies the object being accessed. How does an NFS client obtain an NFS file handle? Honest clients use the NFS mount protocol. When an NFS client host wants to access a remote file system for the very first time, the client host sends a mount request to the file server’s mount daemon. The mount daemon verifies that the client host has permission to access the file system. When the mount daemon grants access, it sends an NFS file handle back to the client. Once an NFS client has a file handle, it can send file access commands directly to the file server’s NFS daemon. In fact, any client that is in the possession of a valid NFS file handle can use it. Export restrictions are primarily enforced by the mount daemon. In the most common cases the file server’s NFS daemon does not care what client is talking to it. How, then, does an NFS server protect itself against malicious clients that make up their own NFS file handles? SUN’s solution was to make NFS file handles hard to guess. When a file system is created, the fsirand program initializes all NFS file handles with pseudo-random numbers. The program is seeded with a process ID and with the time of day. Unfortunately, early fsirand implementations did not initialize the time of day variable. Because of this missing initialization, the time of day variable contained fixed garbage values, depending on the system architecture. Only the process ID was being set [Dik96]. Many sites run the same suninstall procedure to install the operating system onto their disks. This procedure is highly automated, and by implication, the fsirand process ID is very predictable. Unknowingly, many sites initialized their file systems with the same NFS file handles world wide. Thus, in order to access a file system there was no need to use the NFS mount protocol at all. Every other house in the street did have the same keys to the front door. While researching this paper I noticed that many systems do not even have an fsirand command or its moral equivalent. Some systems simply use the time of day when allocating a filesystem inode.